The technical field of this document relates to checking the integrity of stored data, in particular of firmware or software. Such software or firmware is suitable for controlling field units, sensors, actuators, DVD drives, hard drives or the like. These can furthermore be suitable for communicating by a network with one another or with other units, such as servers or personal computers. If these units are physically unprotected however, then attackers have the facility to access the software or firmware in particular for the purpose of reverse engineering. There is also a danger of manipulated software or firmware being brought back onto the corresponding unit.
Security against manipulation of the software or firmware for the corresponding unit could be achieved by hardware measures, such as sealing the unit for example. No further manipulation is possible after the unit has been sealed. Any subsequent intentional and desired, legal firmware update would then however also no longer be possible.
A further protection capability can be achieved by checking the integrity and authenticity of the firmware installed during the firmware update based on digital signatures. This does however presuppose that a check can be performed during the installation procedure and the memory chip for the firmware is not simply replaced.
As a further option affording security against manipulation a method is known internally to the applicant for performing a software integrity check for a unit by calculating a checksum for the software currently present and comparing the calculated checksum with a stored checksum. In this situation, the checksum can be designed as a cryptographic checksum and the stored checksum can be stored signed. Thus, when the corresponding unit is connected by a network, other network nodes or devices can interrogate this checksum by way of the existing communication channels and compare it with the desired value. However, if the software of the corresponding unit is overwritten by a manipulated firmware update, then this checking capability is also rendered inoperative because the manipulated unit also continues to be able to respond to inquiries for its checksum with the desired value, provided the corresponding checksum remains stored in the manipulated unit. Then although the stored checksum no longer corresponds to the actual checksum of the software currently present in the corresponding unit, this is however permanently stored in the manipulated unit so as to feign the integrity of the stored software.